CIAC Advisory F-08: IP Address Spoofing and Hijacked Session Attacks (fwd)
Mark Crother (mcrother@dee.retix.com)
Mon, 23 Jan 1995 16:35:40 -0800 (PST)
Here is what I got from CIAC today on the NYT mentioned ip spoofing
attacks.
Forwarded message:
>
> _____________________________________________________
> The U.S. Department of Energy
> Computer Incident Advisory Capability
> ___ __ __ _ ___
> / | /_\ /
> \___ __|__ / \ \___
> _____________________________________________________
>
> ADVISORY NOTICE
>
> Internet Address Spoofing and Hijacked Session Attacks
>
> January 23, 1994 1100 PST Number F-08
> _____________________________________________________________________________
>
> PROBLEM: Sophisticated new attacks on Internet systems based on
> forged IP packets and hijacked login sessions.
> PLATFORMS: Primarily Unix systems connected to the Internet, although
> all systems that support session authentication based on IP
> addresses are potentially vulnerable. Systems protected by
> packet filtering firewalls may also be vulnerable.
> DAMAGE: Unauthorized privileged access to systems.
> SOLUTION: Enable router packet filtering on inbound Internet traffic,
> and protect systems against root compromise.
> _____________________________________________________________________________
>
> VULNERABILITY These attacks represent a significant new threat to Internet
> ASSESSMENT: systems. Without proactive measures in place, these attacks
> are very difficult to detect or defend against. CIAC strongly
> recommends sites implement the solutions described below as
> soon as is possible.
> _____________________________________________________________________________
>
> Critical Information about the Internet Attacks
>
> CIAC has received information regarding a new attack technique on systems
> connected to the Internet. These attacks are based on the exploitation of
> two separate vulnerabilites: forging or spoofing the source address of IP
> packets and hijacking already established login sessions. Although these
> vulnerabilities are currently being used together to attack systems, each
> may also be used on its own. Both of these vulnerabilities must be
> addressed in order to keep systems secure.
>
>
> IP Spoofing Attacks
> -------------------
>
> Description
> -----------
> The first vulnerability, spoofing IP packets, allows an intruder on the
> Internet to effectively impersonate a local system's IP address. If other
> local systems perform session authentication based on the IP address of a
> connection (e.g. rlogin with .rhosts or /etc/hosts.equiv files under Unix),
> they will believe incoming connections from the intruder actually originate
> from a local "trusted host" and will not require a password. This technique
> is especially damaging when root connections are permitted with no password.
>
> Services that are vulnerable to forged IP packets include:
> SunRPC & NFS
> BSD Unix "r" commands, including rlogin
> Services secured by TCP Wrappers using source address access control
> X Windows
>
> It is possible for forged packets to penetrate firewalls based on filtering
> routers if the router is not configured to block incoming packets with
> source addresses in the local domain. It is important to note that this
> attack is possible even if no session packets can be routed back to the
> attacker. Note also that this attack is not based on the source routing
> option of the IP protocol.
>
> The IP spoofing attacks are very similar to those described in section 2
> of "Security Problems in the TCP/IP Protocol Suite" by Steve Bellovin. This
> paper was published in _Computer Communication Review_ vol. 19, no. 2 (April
> 1989), pages 32-48. It is also available via anonymous FTP from
> research.att.com in the file /dist/internet_security/ipext.ps.Z.
> Additional information is available in the paper "A Weakness in the 4.2BSD
> Unix TCP/IP Software," by Robert T. Morris. It is also available via
> anonymous FTP from research.att.com in the file
> /dist/internet_security/117.ps.Z.
>
> Detection
> ---------
> IP spoofing attacks are currently very difficult to detect. If your site
> has the ability to monitor network traffic on the external interface of your
> Internet router, examine incoming traffic for packets with both a source
> and destination address in your local domain. Such packets should never be
> found entering your site from the Internet and are a strong indicator that
> an IP spoofing attack is in progress.
>
> Users within the Deparment of Energy (DOE) and Department of Defense (DOD)
> communities may obtain a new version of the Network Intrusion Detector (NID)
> with added features allowing the detection of IP spoofing attacks. Please
> contact Bob Palasek, NID Project Leader, at (510) 422-8527 or
> palasek@llnl.gov, for more information.
>
> Additionally, two freely available software tools are known to allow this
> type of packet monitoring on Unix systems: tcpdump and netlog. The tcpdump
> package is available via anonymous FTP from ftp.ee.lbl.gov in the file
> /tcpdump.tar.Z (MD5 checksum 4D8975B18CAD40851F382DDFC9BD638F). When built
> and installed, the command
>
> # tcpdump src net X.Y and dst net X.Y
>
> will print all packets found that claim to have both a source and
> destination IP address on the X.Y network. The netlog package, developed at
> Texas A&M University, is available via anonymous FTP at coast.cs.purdue.edu
> in the file /pub/tools/unix/TAMU/netlog-1.2.tar.gz (MD5 checksum
> 1DD62E7E96192456E8C75047C38E994B). When built and installed, it may be
> invoked with the command
>
> # tcplogger -b | extract -U -e 'srcnet=X.Y.0.0 && dstnet=X.Y.0.0 {print}'
>
> to scan for packets with a source and destination address on the same
> network.
>
> Prevention
> ----------
> Currently, the best defense against IP spoofing attacks is to filter packets
> as they enter your router from the Internet, blocking any packet that claims
> to have originated inside your local domain. This feature, known as an
> input filter, is currently known to be supported by several brands of
> routers:
>
> Bay Networks/Wellfleet, version 5 and later
> Cabletron with LAN Secure
> Cisco, RIS software version 9.21 and later
> Livingston
> NSC
>
> If your current router hardware does not support packet filtering on
> inbound traffic, a second router may be installed between the existing
> router and the Internet connection. This second router may then be used
> to filter spoofed IP packets with an output filter.
>
>
> Hijacked Session Attacks
> ------------------------
>
> Description
> -----------
> The second attack currently being observed involves the use of a tool
> called "tap" to take over existing login sessions on a system. This tool
> allows an intruder with root access to gain control of any other session
> currently active on the system, executing commands as if they had been
> typed by the owner of the session. If the user session has previously
> performed a telnet or rlogin to another system, then the intruder may gain
> access to the remote system as well, bypassing any authentication normally
> required for access.
>
> Currently, the tap tool is only known to affect SunOS 4.1.x systems,
> although the system features that allow the attack are not unique to Sun
> systems.
>
> Detection
> ---------
> The owner of the hijacked session may notice unusual activity, including
> the appearance of commands typed by the intruder. Users should be
> notified of this possibility and encouraged to report any suspicious
> activity.
>
> Prevention
> ----------
> The primary defense against this attack is to prevent root compromise
> through careful system management, installation of security patches, and
> network controls such as firewalls.
>
> The tap tool currently in use makes use of SunOS loadable module support
> to dynamically modify the operation of the running Unix kernel. CIAC
> recommends that sites not requiring loadable modules disable this feature
> on their SunOS 4.1.x systems.
>
> To do so, edit the kernel configuration file found in the
> /sys/`arch -k`/conf directory and comment out the following line with a
> "#" character:
>
> options VDDRV # loadable modules
>
> Then build and install the new kernel:
>
> # /etc/config CONFIG_NAME
> # cd ../CONFIG_NAME
> # make
> # cp /vmunix /vmunix.orig
> # cp vmunix /
> # sync; sync; sync
>
> Finally, reboot the system to activate the new kernel. Note that
> intruders have been known to regenerate their own kernels and reboot
> systems to install the functionality they desire. The authenticity of the
> running kernel should be verified after any unexplained system reboots.
>
> _____________________________________________________________________________
>
> CIAC wishes to acknowledge the contributions of the CERT Coordination
> Center, Eric Allman, Steve Bellovin, Keith Bostic, Bill Cheswick, Mike
> Karels, and Tsutomu Shimomura for their assistance in the construction of
> this bulletin.
> _____________________________________________________________________________
>
> For emergencies and off-hour assistance, DOE and DOE contractor sites can
> contact CIAC 24-hours a day via an integrated voicemail and SKYPAGE number.
> To use this service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The
> primary SKYPAGE PIN number, 8550070 is for the CIAC duty person. A second
> PIN, 8550074 is for the CIAC Project Leader. CIAC's FAX number is
> 510-423-8002, and the STU-III number is 510-423-2604. Send E-mail to
> ciac@llnl.gov.
>
> Previous CIAC notices, anti-virus software, and other information are
> available on the Internet via anonymous FTP from ciac.llnl.gov (IP address
> 128.115.19.53).
>
> CIAC has several self-subscribing mailing lists for electronic publications:
> 1. CIAC-BULLETIN for Advisories, highest priority - time critical
> information, and Bulletins, important computer security information;
> 2. CIAC-NOTES for Notes, a collection of computer security articles;
> 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI)
> software updates, new features, distribution and availability;
> 4. SPI-NOTES, for discussion of problems and solutions regarding the use of
> SPI products.
>
> Our mailing lists are managed by a public domain software package called
> ListProcessor, which ignores E-mail header subject lines. To subscribe (add
> yourself) to one of our mailing lists, send requests of the following form:
>
> subscribe list-name LastName, FirstName PhoneNumber
>
> as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES,
> SPI-ANNOUNCE or SPI-NOTES for "list-name" and valid information for
> "LastName" "FirstName" and "PhoneNumber." Send to: ciac-listproc@llnl.gov
> not to: ciac@llnl.gov
>
> e.g.,
> subscribe ciac-notes O'Hara, Scarlett 404-555-1212 x36
> subscribe ciac-bulletin O'Hara, Scarlett 404-555-1212 x36
>
> You will receive an acknowledgment containing address and initial PIN, and
> information on how to change either of them, cancel your subscription, or get
> help.
> _____________________________________________________________________________
>
> PLEASE NOTE: Many users outside of the DOE and ESnet computing communities
> receive CIAC bulletins. If you are not part of these communities, please
> contact your agency's response team to report incidents. Your agency's team
> will coordinate with CIAC. The Forum of Incident Response and Security Teams
> (FIRST) is a world-wide organization. A list of FIRST member organizations
> and their constituencies can be obtained by sending E-mail to
> first-request@first.org with an empty subject line and a message body
> containing the line: send first-contacts.
>
> This document was prepared as an account of work sponsored by an agency of
> the United States Government. Neither the United States Government nor the
> University of California nor any of their employees, makes any warranty,
> expressed or implied, or assumes any legal liability or responsibility for
> the accuracy, completeness, or usefulness of any information, product, or
> process disclosed, or represents that its use would not infringe privately
> owned rights. Reference herein to any specific commercial products, process,
> or service by trade name, trademark manufacturer, or otherwise, does not
> necessarily constitute or imply its endorsement, recommendation, or favoring
> by the United States Government or the University of California. The views
> and opinions of authors expressed herein do not necessarily state or reflect
> those of the United States Government nor the University of California, and
> shall not be used for advertising or product endorsement purposes.
>
>
--
Mark Crother mcrother@retix.com
Internetworking Systems Engineer Retix